In a multimaster database system, data is stored in a group of databases, data changes may be made to any member of the group, and data changes made to one member are propagated to the rest of the group. Multimaster database systems typically employ either a “synchronous” or an “asynchronous” replication scheme for propagating a change made to one database to the rest of the databases in the group.
In synchronous multimaster replication, each change is applied to all databases in the group immediately or to none of the databases if one or more of the databases in the group cannot accept the change. For example, one of the databases may be offline or unavailable. Synchronous multimaster replication is typically achieved using a two-phase commit protocol.
In contrast, in “asynchronous” multimaster replication, a change made to a database is immediately accepted by the database but propagation of the change to other databases in the group may be deferred. Because propagation of changes may be deferred, if one or more of the databases in the group are unavailable, the available databases can still accept changes, queuing the changes locally until they can be propagated. For this reason, multimaster database systems employing an asynchronous replication strategy are considered to be more highly available than multimaster database systems employing a synchronous replication strategy. However, asynchronous replication raises the possibility of conflicts that occur as a result of concurrent database changes.
A conflict can arise in a multimaster database system when the same data is changed in two different databases before either one of those changes can be propagated to the other. For example, assume that in database A data representing a particular person's eye color is changed to “brown”, and after that change but before that change can be propagated to database B data in database B representing the particular person's eye color is changed to “green”. Without additional information, it is unclear which change is the “correct” change that should be adopted by all databases in the system.
Multimaster database systems employing an asynchronous replication scheme typically provide mechanisms for “deconflicting” conflicts. As used herein, the term “deconflict”, refers generally to detecting and resolving a conflict such that a resolution of the conflict is eventually adopted by all databases in the system. In some cases, the multimaster database system may be able to deconflict automatically without requiring user intervention. In other cases, user intervention may be required to determine which of the concurrent changes should be adopted.
In multimaster database systems employing asynchronous replication, when conflicts are detected has an enormous effect on the integrity of database data. For example, some database systems may support “object resolution”. Object resolution involves a user or an automated computing process determining that two or more separate data objects actually represent the same real-world entity and invoking a function of the database system so that the separate data objects are resolved into a single data object. For example, assume there are two separate data objects, one having a name property value of “John Smith”, the other having a name property value of “J. S.”. A user may decide that these two data objects both represent the same real-world person. Accordingly, in a database system that supports object resolution, the user may invoke a function of the database system so that the two separate data objects are resolved to a single data object having a name property value of “John Smith” or “J.S.” as selected by the user resolving the objects together.
In multimaster database systems employing asynchronous replication, it would be desirable to detect as a conflict concurrent changes that include an object resolution change. For example, assume that in database A, User 1 changed the hair color property of a data object representing a person named “J.S.” from “brown” to “blonde”. Further assume that before the hair color change made by User 1 can be propagated from database A to database B that User 2 changes database B by resolving together the data object representing “J.S.” with another data object representing a person named “John Smith”. It would be desirable for the multimaster database system to detect these two concurrent changes as a conflict as User 2 may not have decided to resolve “J.S.” and “John Smith” together if User 2 had known that John Smith's hair color was changed by User 1. Similarly, User 1 may not have decided to change the hair color of “J.S.” had User 1 known that User 2 resolved “J.S.” and “John Smith” together.
What is a needed then is a multimaster database system employing asynchronous replication that detects conflicts resulting from concurrent changes in a manner that is in line with user expectations and that handles the deconfliction and propagation of such changes appropriately. Embodiments of the present invention fulfill these and other needs.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.